An exception is an event that disrupts the normal flow of instructions during execution of a computer program. Exceptions are generally but not exclusively used to signal error conditions, such as an unexpected null pointer encountered during an attempt to access memory, a malformed structure encountered during parsing, or a lack of resources encountered during execution. Conditions that may cause a resource exception include memory full, network connection failed, and others.
Exception handling is the process of dealing with an exception. The handling process may include saving state information, updating a log, printing an error message, retrying an operation, trying an operation with different parameters and/or trying an alternate operation, converting an exception from one type to another type for handling by code elsewhere in the program, and/or other operations. Exception handling mechanisms may allow a program designer to centralize exception handling for easier maintenance or modifications by providing ways to separate, from the main logic of a program, the details of what to do when something out of the ordinary happens during execution.
Some software architectures allow a host program to interact with a plug-in program. Plug-ins are sometimes called add-ins. A plug-in may be provided and updated by a different vendor than the host that runs the plug-in. The allowed interactions between the host and the plug-in are specified in an API or other interface contract. Supporting plug-ins allows a host program to provide its users with additional functionality while nonetheless hiding implementation details in the plug-in. Accordingly, a host need not always depend on a particular plug-in implementation, but could rely instead only on the functionality specified in the contract between the host and the plug-in.
Software architectures that provide exception handling mechanisms do not necessarily also support plug-ins. Likewise, architectures that support plug-ins do not necessarily also provide exception handling mechanisms.
Indeed, a tension exists when designing an architecture that includes both exception handling and plug-ins. One program design approach would centralize exception handling code, so that all exceptions caused by network connection failures are handled in a consistent way, for example. A second approach would hide exception handling and other plug-in implementation details inside the plug-in, so that plug-in data structures and algorithms can be modified without changing the host code, for example. The first approach views the host and plug-ins as if they are a single program, in which exception handling and other operations should be centralized for consistency and efficiency. The second approach views the host as being largely separate from the plug-ins, in that each code component should keep its implementation details separate from the other, in order to allow greater flexibility to their respective vendors. In particular, the second approach favors plug-in version changes that are transparent to users of the host.